Group Fields
A group field (often referred to simply as a group) is a series of one or more fields with contiguous sequence numbers that can be referenced by a single field name. Groups are defined for those instances where it is of benefit to access fields both individually and as a unit, depending uponthe specific requirements of an operation or display. For example, group fields are often used to define multipart keys.
A group field's primary purpose is to simplify data assignments and comparisons between two sets of fields with matching contents, formats, and storage types. You can only reference a group field in a statement or within selection criteria, or specify it as a key. You cannot, for example, paint a group as an item in an image.
APPX treats all components of a group field as physically contiguous, regardless of how they are stored. This is particularly significant when you use a group in an assignment or a comparison. For example, assume you compare two group fields, both 15-bytes-long. Group A is composed of two noncontiguous components: 10 bytes and five bytes. Group B is composed of three noncontiguous components: three bytes, 10 bytes, and two bytes. APPX does not compare the first component of group A with the first component of group B. Rather, it compares the first three bytes of group A with the first three bytes of group B, the next seven bytes of group A with the next seven bytes of group B, and so on. The same is true for an assignment. APPX treats groups as a contiguous string of bytes for purposes of both comparison and assignment.
You create a group by defining a group header and, optionally, group trailer field.
A group header is a field that serves simply to mark the beginning and end of a series of contiguous (physically adjacent) fields in a concatenation or group. This group of fields can be referenced by the name assigned to the group header field.
A group trailer field is an optional placeholder to mark the position of the final field in a group. It simplifies group maintenance by providing a streamlined mechanism to allow for future additions to the end of a group. As with a group header field, a group trailer occupies no physical space in a file.
Group header and group trailer fields occupy no separate physical space in a file and serve only as placeholders to mark the beginning and end of a series of contiguous fields which you can access as a unit.
A group field itself, bounded by a group header and trailer, references one or more contiguous fields through a single field name. A group does not store a separate copy of data contained in component fields. Both a group field and the component fields it references access the same physical data. In fact, more than one group field can access the same component fields (nested group fields), as long as one group is completely contained within another group. Groups with partially overlapping physical storage are not permitted; in other words, any two groups cannot share a component field unless they share all the component fields in one of the groups. Refer to the Group Fields section for additional rules and restrictions.
The attributes of a group field are not simply equal to the sum of the attributes of component fields. The content of a group is actually based on the internal format of all of its components. The only exception is the sort function of a query process, for which a group field reflects the attributes of its component fields. For example, for the purpose of the sort only, there is no difference between the numeric value in a group field and the numeric field itself.
APPX considers a group to be a basic alpha field (a single string of alphanumeric characters that are not specially formatted), regardless of how component fields are defined. If all components are not basic alpha fields, APPX performs no special translation when a group is used in a comparison or an assignment. Refer to the Field Types section for the definition of a basic alpha field.
The distinctions between the attributes of a group and its component fields have several important ramifications:
By manipulating a group, rather than the component fields, you run the risk of placing invalid data into a component field. For example, if your group includes a packed decimal field and you set it to AAAA, you replace the data in the field with data that is not valid for a packed decimal number.
APPXcompares two strings of bytes with no translation or error checking. It does not warn you that a comparison is not based upon like component fields in a group. For example, assume you are using two groups (A and B) in the statement, IF A EQ B. A is composed of a customer number and a transaction number, and B is a transaction number and date. APPX compares these two group fields and returns a false, not an error, condition.
Comparing two group fields does not always yield the same result as comparing the individual components of two groups.Assume the A and B group fields in the previous example are both comprised of customer number and transaction number, but the customer number in one is an alphanumeric and, in the other, a numeric field. If APPX compares a customer number of 100 in A to a customer number of 100 in B, it is capable of converting the values in these two fields to an intermediate format for comparison and returning a true condition. The same comparison, if based upon the groups rather than the component fields, returns a false condition.
These differences in attributes are particularly significant if you manipulate group data with statements. Refer to ILF Integration for a discussion of APPX statements. |